Traditionally, collated, face-up printing has been performed through the use of print drivers or printer firmware/hardware. Special print drivers may be used to implement custom printing features, however print drivers are printer specific. Each printer or group of closely-related printers must have its own driver, therefore, implementing special features across a variety of printing devices requires the customization of a multitude of print drivers. Implementation of a new feature across the thousands of available printers today and new printers as they are introduced can be an endless task.
Furthermore, many of the algorithms used for these processes require the last page of a document to be rendered before the sheets are printed. This requires storage of the rendered data on the host computer until the entire print job is rendered. When compared to immediate despooling of the page data to the printer, these processes can be slow and require expensive hardware and firmware or additional software.
Some advanced printers, containing a microcomputer processor and disk (firmware), and additional mechanical components (rollers) can accomplish collated, face-up printing within the printer itself, alleviating the need of the print driver support and storage on the host computer.
What is needed is a simple, cost-effective method of achieving collated, face-up printing without the added complexity, expense and delay of current implementations.
Many computing device platforms and printing systems are available today and embodiments of the present invention may be implemented with many of these systems, however, due to the prevalence of the Microsoft Windows® operating system family, embodiments used in conjunction with Windows® systems will be used to illustrate its functions. Accordingly, details of Microsoft Windows 95® and related Microsoft Windows® printing processes will be explained.
Microsoft Windows® operating systems typically employ two file types in the printing process. These file types are Enhanced Metafile (EMF) and raw format (raw) files.
Raw format files are device dependent files which are destined and formatted for a specific device. An example of a raw file is an encapsulated Postscript file, which is formatted to be interpreted by a Postscript printer. EMF files are device independent which contain graphic device interface (GDI) function calls that reproduce an application's graphic objects on a printer. EMF files are used to quickly record a printed document and return system control to a user. After control is returned to the user, the function calls stored in the EMF file may be executed and sent to the printer in the background.
Files may be recorded for later play back by using a spool file that is written and later despooled to a printing device. Spool files may be used for EMF and raw files. However, a print job may also be written directly to a printing device without using a spool file. Some typical printing process scenarios using raw spool files and EMF spool files are described below to introduce the elements and relationships of these processes and how they relate to embodiments of the present invention. These scenarios are derived from information contained in the Microsoft Windows 95® Driver Development Kit (DDK) documentation, the Microsoft Windows 2000® DDK documentation and the Microsoft Windows NT® DDK documentation.
A typical printing process scenario using a raw spool file may be described in reference to FIG. 1 wherein an application 10 initiates a print request 1 by calling a graphic device interface (GDI) 12. Application 10 may be a word processor, spreadsheet, browser, database program or some other program that runs on the underlying operating system. Typically, application 10 will create a device context (DC) and draw an object (i.e., a circle, a line, etc.) to the DC. The application 10 will then call the GDI with a print request directed to a particular printer 16 (FIG. 2) using that DC.
The GDI 12 will call the printer driver 14 associated with the particular printer 16 and request 2 instructions on how to render the object on that particular printer 16. The printer driver 14 will return 3 the instructions on how to render the object on the printer 16. In Windows 95®, used in this printing process example, the printer driver 14 is written in 16-bit code and communicates with a 16-bit GDI 12. This GDI will then pass the print request to a 32-bit GDI (GDI32) 18 to handle the 32-bit Windows 95® spooler process. GDI32 makes an interprocess call 5 to the spooler process 20.
Spooler process 20 calls 6 the router 22 to route the print job to printer 16. In this example, illustrated in FIGS. 1-2, the router 22 sends the print job to a local print provider 24. In other scenarios, the router 22 may send print jobs to a network printer through a network print provider (not shown). When the default Windows 95® spooler is used, network print jobs are spooled and despooled on the client machine just as local print jobs. The network print server is contacted only during despooling. Windows NT/2000® client machines handle print jobs to network print servers differently, these machines use remote procedure calls (RPCs) to call the necessary printing application program interfaces (APIs) on the print server. In these NT/2000 scenarios, the print jobs do not show up on the local spooler queue, spooling and despooling are handled by the print spooler on the print server. This RPC method can be used in conjunction with Windows 95® spoolers also. Print jobs to locally connected printers or locally queued to (e.g., LPR) to network printers are handled similarly to Windows 95, 98 local print jobs.
In this local printing scenario, the router 22 calls the local print provider 24 with the print job. Local print provider 24 writes or “spools” 8 a raw spool file 26 to disk for later access. This is done to avoid waiting for the printer to complete the job before control is returned to the application. These steps from initiating the print request 1 to writing to spool file 26 may be repeated many times. Data may be appended to spool file 26 until an application signals that the print job is complete. This may be signalled with an EndDoc function. Local print provider 24 also starts 9 a background thread 28 that will determine the best time to start playing back or “despooling” the spool file 26 to the printer 16.
In reference to FIG. 2, Thread 28 monitors spooler subsystem resources to determine a good time to playback spool file 26. When thread 28 determines that playback should commence, a StartDoc function call 17 is sent to print processor 32 to start a new print processor thread 11. Print processor thread 11 invokes the local print provider 24 with a ReadPrinter function call to read part of the spool file 26. A print processor thread 12 also uses the local print provider 24 to invoke the language monitor 34 with a WritePrinter function call to send data through the physical port 38 connected with the bidirectional printer 16 specified previously.
For raw spool files, the default print processor 32 simply passes data through without changing or interpreting any of the information. A language monitor 34 is used in this example because the destination printer 16 is a bidirectional printer. When non-bidirectional printers are used a port monitor 36 would be invoked instead of the language monitor 34. A language monitor 34 and port monotor 36 may be separate components or may be integrated into one monitor.
Language monitor 34 calls 13 a port monitor 36 to send print job data to the printer 16. The port monitor 36 then sends 15 the raw data through the physical port 38 to the printer 16. This process of reading from a spool file 26 and forwarding data to the printer 16 may be repeated several times to complete a print job. This is typically repeated until an end-of-file is reached or the job is cancelled. The playback thread 12 is terminated at that point. The combination of spooler process, router, local print provider, print processor, language monitor and port monitor may be referred to collectively as a “spooler” 30.
When Windows Enhanced Metafile (EMF) format files are used in the printing process of Windows 9.x systems, process components interact differently than with raw files. An example printing process, shown in FIGS. 3 and 4 illustrates the printing process using EMF files.
This process typically commences when an application 40 creates a printer DC and draws an object to the DC (not shown). The application 40 then calls 41 GDI 50 with an EMF spooling request for a designated printer 68. GDI 50 queries 42 the printer driver 52 associated with the designated printer 68 to determine whether the driver 52 supports EMF spooling. If the driver 52 supports EMF spooling, GDI 50 changes the printer DC to an EMF DC and writes 43 the instructions for rendering the object to the EMF DC 54 (creates EMF files). GDI 50 then passes 44 the print request to the 32-bit GDI (GDI32) 56 because, in this example the Windows 95® spooler process is 32-bit code. GDI 32 subsequently makes an interprocess call 45 to the spooler subsystem 70 with a description of the print job.
The spooler process 58 (SPOOL32.EXE), in the spooler system 70, calls the router 60 to pass the print job description to the print provider 62 that can reach the designated printer 68. In this example, a local print provider 62 is used, but a network print provider may also be used. When the default Windows 95® spooler is used, network print jobs are spooled and despooled on the client machine just as local print jobs. The network print server is contacted only during despooling. Windows NT/2000® client machines handle print jobs to network print servers differently, these machines use remote procedure calls (RPCs) to call the necessary printing application program interfaces (APIs) on the print server. In these NT/2000 scenarios, the print jobs do not show up on the local spooler queue, spooling and despooling are handled by the print spooler on the print server. This RPC method can be used in conjunction with Windows 95® spoolers also.
When the router 60 has called the print provider 62, the local print provider 62 creates 48 a job description file 64 and adds 48 a record to the job description file 64 each time it is called for the job until all the EMF page files have been spooled and each EMF file name and location is recorded in the job description file 64. When information about the last EMF file in the print job has been recorded, the local print provider 62 will call the spooler process 58 with an EndDoc function call. This signals the spooler process 58 that the complete job is spooled and ready for despooling. For multi-page jobs, these steps from initial spooling request 41 to job description file recording 48 are repeated for each page of a job.
When EMF file spooling is complete, the spooler process 58 sets a ReadyToPrint attribute on the print job and initiates an event 49 that signals to the port thread 66 that a job is available for printing. Port thread 66 responds to this event by determining the best time to start the despooling process and, at that time, loads 81 the print processor 72, as shown in FIG. 4. The print processor 72 will determine that the file format is EMF and call GDI32 56 with a Windows 95® function call 82.
GDI32 then invokes a gdiPlaySpoolStream function to read 83 from the job description file 64 which provides a fully qualified path to an EMF spool file 54. Through the job description file 64 which comprises a list of path names to EMF files, GDI32 knows about all the pages in the print job. The GDI32 gdiPlaySpoolStream function also calls GDI 50, using a thunk built into GDI32, with the path to the EMF spool file to render the page. GDI 50 only knows about one page in the print job at a time.
GDI 50 calls the printer driver 52 associated with the designated printer 68 chosen in application 40 and obtains a DC for the printer 68. GDI 50 then reads page-rendering instructions from the spooled EMF file 54 and passes 85 them one at a time to the printer driver 52 which uses as many instrucitons as are necessary to render the first part of the page. When the 16-bit printer driver 52 renders a part of the page, it passes 87 the printer-specific raw page data back to the GDI 50 which, in turn, passes 88 the raw data to GDI32 56. GDI32 56 then passes 89 the raw data to the spooler process 58 which then follows the same procedures it would for a raw format files as explained above.
Spooler process 58 calls 90 the router 60 to route the print job to printer 68. In this example, illustrated in FIGS. 3 and 4, the router 60 sends the print job to a local print provider 62. In other scenarios, the router 60 may send print jobs to a network printer through a network print provider (not shown). In this local printing scenario, the router 60 calls the local print provider 62 with the print job. Local print provider 62 invokes the language monitor 74 with a WritePrinter function call to send data through the physical port 78 connected with the bidirectional printer 68 specified previously.
A language monitor 74 is used in this example because the destination printer 68 is a bidirectional printer. When non-bidirectional printers are used a port monitor 76 would be invoked instead of the language monitor 74. A language monitor 74 and port monitor 76 may be separate components or may be integrated into one monitor. Language monitor 74 calls 93 a port monitor 76 to send print job data to the printer 68. The port monitor 76 then sends 94 the raw data through the physical port 78 to the printer 68.
Parts of EMF pages are processed in this manner and printed until an entire page is printed. GDI32 56 then gets the path to the EMF spool file for the next page and calls GDI 50 to use the instructions in that EMF file to render the next page of the print job. The print job is finished when all the paths to EMF spool files are used up.
Other versions of the Microsoft Windows operating systems, such as Windows NT and 2000 may use different printing processes as described with reference to FIG. 5. These processes may be used to print data to local, network and remote printers either directly or through a network print server. EMF data may also be processed differently. For example, in Windows NT and 2000, the entire EMF data for all pages is passed to GdiPlayEMF( ) in one pass, rather than one page at a time. If the EMF data is to be queued on a print server, the EMF data is passed directly to the print server without rendering on the client. A mirror copy of the driver on the server renders the EMF data instead.
Typically, a user will employ an application 100 to create a print job by calling GDI 102 functions. The GDI 102 and/or application 100 will then call Winspool.drv 104 which is a client interface into the spooler. This client interface, Winspool.drv 104, exports the functions that make up the spooler's Win32® API and provides RPC stubs for accessing the server. The print job is then forwarded to the spooler's API server, Spoolsv.exe 106 which can be implemented as a Windows 2000 service that is started when the operating system is started. This API server module exports an RPC interface to the server side of the spooler's Win32® API. This module implements some API functions, but most function calls are passed to a print provider by means of the router, spoolss.dll 108.
The router 108 determines which print provider to call, based on a printer name or handle supplied with each function call, and passes the function call to the correct provider 110, 112 or 114. If the selected printer is managed by the client system, the print job is handled by the local print provider, localspl.dll 110. Printers managed by the local print provider 110 do not have to be physically local to the client, they may also be directly connected to network cards without using a server. When these printers are used, the print job is passed to the kernel-mode port driver stack 116 and on to the printer 118.
When printers located on a Windows NT/Windows 2000 server are selected, the router 108 directs the print job to the network print provider, Win32spl.dll 112. This network provider uses RPC to redirect calls from the client's router to the network server's spoolsv.exe process 124 which forwards the print job to the network server's router 126. Because the network printer is local to the print server system, the network server router 126 routes the job to the server's local print provider 128. The job is then directed to the server's kernel-mode port driver stack 130 and out to the selected network printer 132.
Remote printers may also be used with these systems. When a remote printer is selected, the client router 108 may direct the print job to the local print provider 110 which will forward the job to the kernel-mode port driver stack 116 and on to the remote printer 142 using a network protocol. When the local print provider 110 accesses a remote printer 142, the provider 110 uses a port monitor that can use network protocols recognized by the remote printer or its server.
Printers managed by non-Windows NT/2000 servers (e.g., Novell servers) may also be accessed through this print system. This may be achieved by using a local print provider 110 which directs the print job to the kernel-mode port driver stack 116 and on to the printer's server 136 using a type of network protocol. The server 136 then directs the job to the destination printer 140. This may also be achieved using a customized print provider 114 which sends the job to the kernel-mode port driver stack 116 which uses a network protocol to send the job on the the printer's server 134 which then directs the job to the destination printer 138.
An example of these printing processes may be explained with reference to FIG. 6 which illustrates a Windows 2000 print process. In this process, an application 150 is used to create a print job with the Graphics Device Interface (GDI) 152. When the print job's initial output file is in raw format (not EMF) 154, the printer driver's printer graphics DLL 156 works in conjunction with the GDI 152 to create a print job that is sent to the client interface 160 of the spooler. Client interface 160 sends the job to the API server 162 which forwards the job to the router 164. In this example, the router 164, sends the job to the local print provider 165 as it is a local print job.
Within the local print provider 165, a print job creation API 168 is invoked. This API 168 accesses the printer driver's printer interface DLL 174 and creates a job spool file 176. The job creation API 168 also forwards job information to the job scheduling API 170 which initiates a job scheduler thread 172.
At this point, the file format is checked 178. If the initial job file is in a raw format (not EMF) already, the job is sent to the language monitor DLL 182 and on to the port monitor 184 which sends the job to the kernel-mode port driver stack 186. Port driver stack 186 sends the job to the selected printer 188 for final printing.
When an application 150 creates a print job with GDI 152 in EMF format, the job is sent 154 to a client spooler interface 160. Client interface 160 sends the job to the API server 162 which forwards the job to the router 164. Again, in this example, the router 164, sends the job to the local print provider 165 because the print job is local.
Within the local print provider 165, a print job creation API 168 is invoked. This API 168 accesses the printer driver's printer interface DLL 174 and creates a job spool file 176. The job creation API 168 also forwards job information to the job scheduling API 170 which initiates a job scheduler thread 172.
At this point, the file format is checked 178. If the initial job file is in EMF format, the job is sent to the print processor DLL 180 which directs the job back to GDI 152 for conversion to raw format with the help of printer interface DLL 174. The converted job is then sent back through the spooler client interface 160, API server 162 and router 164 to the print provider 165. In the local print provider, the job is processed by the print job creation API 168, job scheduling API 170 and job scheduler thread 172. Because the job is now in raw format, the job is sent to the language monitor DLL 182 and on to the port monitor DLL 184 and kernel-mode port driver stack 186 before arriving at the destination printer 188.